JBoss Community Archive (Read Only)

RHQ 4.7

Arbitrary Resource Operations as Alerts

Current situation

Currently it is only possible to execute operations on the resource, the alert was triggered on. This is not good for situations where e.g. the customer wants to reboot the JBossAS server when his application leaks too much memory, as the reboot action is on the AS resource, while the memory is on the VM resource.

Future

In the future, it will be possible to select a target resource or compatible group, the operation will be run on. The following UI shows this (the current UI has a Edit... button to enable selection of the operation). While the mock up shows the current tab-based layout, it is expected that the Operation sender will end up in the new alert plugin scheme with its updated UI.

 images/author/download/attachments/67240915/ResourceOpsAlerts.png

The existing Edit... button gets replaced by the following:

Operations have a target selector that by default point to this resource (old behavior). When Other resource or Group are selected, the group marked in green is enabled and the user can press „Select..." to get a popup to search for a Resource or compatible group. The popup will (re)use the search boxes from the Resources/Group menu (and if possible also their favorites and last ... sections). After the user has made a selection, it is shown in the text field named „identifier".
If Expression is selected a window pops up to enter an expression. The evaluate button will trigger a syntax check and (if possible and viable in the current state) also show the resulting resource / group.
Either when this resource is selected or the user has selected another resource or group, the operation drop down allows to select an operation to fire and if needed the input fields for operation parameters are shown.
Operations can not be scheduled for future execution, but are directly executed when the AlertNotificationManager schedules them.

Resource Selection

Requirements

  • Continue to support "classic" functionality, which assumes that the operation being executed is on the same resource as that which triggered the alert

  • Be able to select a specific resource in the system

  • Be able to select a "relative" resource in the system

    • Support relative relationship selection for resource-level alert definitions, group-level alert definitions, and alert templates

Option 1 - Custom Form (chosen solution)

Use a custom form that gives a specific, constraint interface that allows each of the cases described above. 

Please select the Resource the Operation should be Executed on:
[ ] Resource this Alert Fires On
[ ] Resource Relative to the Resource this Alert Fires On
  Ancestor of this Resource:  
      type: __(combobox)__  name: __(input)__
  Descendant of Ancestor Specified Above, or of this Resource if Ancestor not Specified:  
      type: __(combobox)__  name: __(input)__
[ ] Specific Resource (resource picker)

Option 2 - DynaGroup-like DSL w/descendant search

// find the Script resource with name *diag*
// under the Platform resource relative
// to the resource that triggered the alert
hierarchy.start=Platform
resource.type=Script
resource.name.startswith=diag

OR 

// find the Script resource with name *diag*
// under the closet ancestor server relative
// to the resource that triggered the alert
hierarchy.start=Server
resource.type=Script
resource.name.startswith=diag

OR 

// find the Script resource with name *diag*
// under the great-grand-parent resource relative
// to the resource that triggered the alert
hierarchy.start=ancestor[3]
resource.type=Script
resource.name.startswith=diag

Option 3 - DynaGroup-like DSL w/ancestor & descendant search

// relative to the resource that triggered the alert,
// look up the ancestry and find the JBossAS Server
// then from there, look down the hiearchy until a
// Script resource with name *diag* is found
up.type=JBossAS Server
up.name=*
down.type=Script
down.name=diag*

Option 4 - XPath-like DSL w/ancestor & descendant filters

../type[script],name=myscript

OR 

 
../../../type[script],name=script-getter/

OR 

../../type[JBossAS:JVM]/type[JMX:Memory]/type[JMX:memorysubsystem],name[perm]

OR 

../../children/type[Memory]/type[memorysubsystem],name[permgen]

OR 

ancestor[type=blah]/descendant[type=foobar]

Tokens and parameters

To pass parameters to an operation, the "normal" operation parameter UI is used like on the Operations tab of a resource.

images/author/download/attachments/67240915/SenderUIMock.png

It will be possible to pass tokens for parameters, that can be interpreted by the plugin sender. The switch determines if the token will be passed literally or replaced by current values. Tokens will follow the RHQ token conventions <% * %> token spaces are

  • alert.* – information about the alert itself

  • resource.* – information about the resource that triggered the alert

  • alertedResource.* – information about the resource the alert is firing the operation on.

Permissions

The user that creates the AlertDefinition needs to be recorded and operation execution needs to be checked against the users permissions at fire time. To reduce unpleasant surprises, the permissions should directly be checked at the time the alert definition is created and operations the user has no rights to execute should not be offered to the user. Alert Auditing needs to contain the user who defined the definition. And especially if the operation could not be executed due to missing permissions at fire time.

Code changes

  • AlertDefinition needs to get a field with an expression that identifies the target resource (e.g. expression and/or fixed Resource/Group Id)

  • Alert needs to get a relation to the target resource or group. In case of a creating an AlertDefinition this can directly be inserted when the Definition is created; in case of an alert template, this gets applied to the Definition at the time the definition is created.

  • AlertManagerBean.triggerOperation() needs to evaluate Alert.target

    instead of taking Alert.resource to schedule the operation

  • The UI will be composed of Facelets that can be rendered as a perspective within the alert definition or alert template definition UI.

  • ResourceManager needs to clean out alerts + alert definitions on removal of a resource that have this resource as target.

  • New plugin code needs to be written to handle the resource selection

  • AlertDefinitions need a relation to subject to record the user who has created this definition

  • Alert auditing needs to record this user.

Migration of existing operations

We need to migrate existing operation alert-notifications. This can be done in two ways:

  • If no target resource is specified, the current one is silently taken. Analogous for the user that created the definition.

  • Have a dbupgrade script fill in the target resource as the one the alert is on. Analogous for the user that gets filled in as overlord

Documentation

Documentation needs to be created on

  • What each option (this resource, other resource, ...) is

  • Refer to the DynaSearch expression language

  • Show an example on how to execute the reboot() operation on a JBossAS server when this server's VM is low on memory (or similar example).

  • Permission handling

Those pieces need to be linked into the general Alert documentation

Required QA

Make sure existing operations continue to work.
Make sure that the right operation is fired for each of this resource / other resource / expression
Check only compatible groups can be selected

Open Questions

Do we want to support groups of resources here at all? Simple resources will allow for a much simpler solution: evaluation of the expression can be done at the time the AlertDefinition is edited, as single resources can not change their members

Tokens for alert-operations sender

Note: remember that all replacements must use the form of <% token %>

alert : Information about the alert itself

  • alert.willBeDisabled: Will the alert definition be disabled after firing?

  • alert.id: The id of this particular alert

  • alert.url: Url to the alert details page

  • alert.name: Name from the defining alert definition

  • alert.priority: Priority of this alert

  • alert.description: Description of this alert

  • alert.firedAt: Time the alert fired

  • alert.conditions: A text representation of the conditions that led to this alert

  • alert.willRecover: ?? TODO

resource : Information about the resource that triggered the alert

  • resource.id: Id of the resource

  • resource.platformType: Type of the platform the resource is on

  • resource.platformName: Name of the platform the resource is on

  • resource.typeName: Resource type name

  • resource.name: Name of the resource

  • resource.platformId: Id of the platform the resource is on

  • resource.parentName: Name of the parent resource

  • resource.parentId: Id of the parent resource

  • resource.typeId: Resource type id

targetResource : Information about the resource the alert is fired on

  • targetResource.parentId: Id of the target's parent resource

  • targetResource.platformName: Name of the platform the target resource is on

  • targetResource.platformId: Id of the platform the target resource is on

  • targetResource.parentName: Name of the target's parent resource

  • targetResource.typeId: Resource type of the target resource id

  • targetResource.platformType: Type of the platform the target resource is on

  • targetResource.name: Name of the target resource

  • targetResource.id: Id of the target resource

  • targetResource.typeName: Resource type name of the target resource

operation : Information about the triggered operation

  • operation.id: Id of the operation fired

  • operation.name: Name of the operation fired

test : Just some dummy tokens for internal testing purposes

  • test.echo: Echo the input

  • test.fix: Return a fixed string

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-12 14:02:43 UTC, last content change 2010-06-10 13:09:15 UTC.